8.7 ストーリー

顧客とプログラマの両方の情報を組み合わせることでよりよい計画を作る (p.276、8.7.8)

ストーリーとは

小さくて顧客に分かる単位

チームが作り出す成果を 1 行か 2 行で シンプルに説明したもの (p.269)

「将来の会話のための約束手形」（アリスター・コーバーン）

チームが動作するソフトウェアを実装してリリースできるほど詳しくは書かれていない (p.269)

ストーリーは要件について詳細な議論をするためのプレースホルダ (p.269)

ストーリーの重要な特徴2つ

顧客価値

顧客にとって価値のある最終的な結果を説明しており、 実装の詳細ではない。(p.269)

顧客はきちんと実装されたことをプログラマに示せる

8.7.1 ストーリーカード

ストーリー間に相対的な優先順位付け

リリース計画に組み入れるストーリーを決める（追加の例）

リリース計画に組み入れるストーリーをプログラマが見積もる

8.7.2 顧客中心

オンサイト顧客には計画ゲームにおいて優先順位付けをする責任がある。(p.271)

技術的な問題に関するストーリーを持たない

各ストーリーの見積りに技術的な検討項目を入れる (p.271)

例：ビルドスクリプトの作成・更新を含める

目的はいつでもソフトウェアをリリースできるようなストーリーを作ること (p.275、8.7.5 質問)

8.7.3 ストーリーを分割したりまとめたりする

ストーリーの大きさは各イテレーションで 4 ~ 10 のストーリーを完了できるぐらいの大きさにしよう。(p.272)

なぜか？（8.7.5の質問）

イテレーションにおいてストーリーが少なすぎると、進捗しているのが分かりにくくなる。(p.275)

（チームのベロシティに応じてストーリーの大きさを調整するということなのかな）

8.7.4 特別なストーリー

（AoAD2eでupdateされた印象）

バグのストーリーはタイムボックスを切る

このバグを調査するのに1日かけるつもりだ。もしそれで修正できなければ、別のストーリーをスケジュールに入れる (p.273)

スパイクストーリー

どうやって見積もるかを調べる

（調べ方は明示しない。目的が果たせればいい）

見積りは予定に入れない＝「いつでも見積りをプログラマに尋ねることができる」(p.274)

ミーティング

研修や出張などいつもと違う予定は、ストーリーを使って予約

（IMO：これは計画するときに消化の予測が減るとして対処したい。AoAD2eでもストーリーを使わないよう修正されている印象）